Along with the fast development of the communication technology and the Internet, merging of the fixed networks, the mobile networks and the Internet has become a general trend, and demands for network services are gradually becoming diversified, integrated, and individualized. Under these circumstances, an open next-generation network architecture is progressively taking shape, which can merge networks of various different structures and comprehensively provide multimedia services.
The fundamental purpose of developing the networks is to provide people with plenty of services, and the service evolvements are driving forces of the fast development of the next-generation networks (NGN). In order to realize merging of the service-layers, a certain approach is required, e.g., universal network interfaces, to shield technical details of the bottom-layers of different networks, so that the upper-layer service applications would have nothing to do with specific network structures, and services across networks of various different structures could be implemented in a uniform way.
The infrastructure of a network is provided by a network service provider, which is the running basis of practical applications provided by a service provider, such as a network operator, a virtual operator, or a third-party service provider. With the development of technology, it is possible to adopt a uniform set of interfaces for abstractly representing service capability of the network, and provide them to the service provider so as to mask discrepancies of the networks and make the networks transparent to the applications (APPs) provided by the service provider, and thus, the applications could uniformly use the capability of the merged network. A representative example herein is a Parlay/OSA Application Programming Interface (API) architecture, including Parlay X Web Services, which defines a set of open interfaces independent of specific techniques and networks, and introduces an application developing mode of the Internet, thereby providing a technical foundation for the merging of IT applications with telecommunication networks. So far, the Parlay/OSA API has won support from numerous standardization organizations and manufacturers, and has become a standard of open network API oriented to Next Generation Networks.
With gradual opening-up of the networks and extensive use of such techniques as interface technique, an issue of how to manage the service providers becomes increasingly prominent. As there is no record for the use of network service capability by applications provided by a service provider in the prior art, it is impossible to conduct management such as charging and performing statistics based on the use of network service capability by the applications provided by the service provider.
In the existing fixed networks, mobile networks, and Internet, there are records of information such as time duration, flow volume, and terminal addresses for users when they consume services, and management could be carried out in connection with these records. Below is a brief description of the structure of the network system in the prior art by taking a system for charging as an example.
FIG. 1 is a schematic diagram illustrating the network architecture in the prior art of implementing charging for users. Typically, the network system comprises an APP 110 provided by a service provider, a network server 120 including a logic processing module 121 and a network operation processing module 122, and one or more network function performing module 130. In order to acquire call detail records (CDR) for charging, the network system further comprises a subscriber CDR processing module 140 as well as a subscriber CDR recording module 123 set in the network server 120.
Here, the APP 110 is for initiating an invocation request to the logic processing module 121 in the network server, where the request contains an identity of the APP 110 itself and invocation parameters; or for receiving performing results from the logic processing module 121 in the network server.
The logic processing module 121 functions to obtain the identity of the APP 110 and the invocation parameters from the received invocation request, and after validating the invocation parameters in the request are appropriate, determine type information of the network service capability providing services to the APP 110 according to the received invocation request, and send a network operating command to the network operation processing module 122, or receive the processing result of network operations from the network operation processing module 122.
The network operation processing module 122 is responsible for analyzing the network operating command received from the logic processing module 121, sending the analyzed command to the corresponding network function performing module 130, analyzing the processing result of network operations received from the network function performing module 130, and returning the analyzed result to the logic processing module 121.
The network function performing module 130 is adopted to perform network operations in accordance with the received command.
The subscriber CDR recording module 123 is in use for receiving the statistical information from the network operation processing module 122, which includes time duration and/or flow volume as well as terminal addresses, recording the received information, and sending the recorded information to the subscriber CDR processing module.
The subscriber CDR processing module 140 takes charge of pricing the received statistical information in accordance with a pre-configured charging matrix of a subscriber's CDR, and generating an account bill for the subscriber.
For the system as shown in FIG. 1, it is possible for the network side to actively initiate a notifying message without subscription by the APP. In this case, the network function performing module 130 is further used for submitting information of a network event to the network operation processing module 122 when a preset triggering condition of the network-side initiative operation is met.
The network operation processing module 122 is further used for analyzing the received information of the network event before submitting the analyzed information to the logic processing module 121.
The logic processing module 121 is further used for, based on the received information of the network event and a preset corresponding relation between the network event and an identity of the APP, obtaining the identity of the APP corresponding to the received network event and type information of the network service capability providing services for the APP, and sending a notifying message to the APP 110.
Whichever processing is made at the network side, the network side will only perform charging for user equipments (UE). Charging for the UEs is mainly implemented by means of statistics of time duration and/or flow volume according to the recorded terminal addresses or other identifiers of the terminals. These recording methods, however, are not applicable for recording and managing applications provided by service providers, for it is quite possible that the time durations or flow volumes consumed by the applications of the service providers are the same or nearly the same, while it doesn't indicate that the occupied network resources of the applications are the same. Therefore, how to make effective records of different network resources occupied by different service providers and amount of the resources used, i.e., use of network service capability by the APPs, remains an issue to be solved.